home *** CD-ROM | disk | FTP | other *** search
- ------------------------------------------------------------------------------
- Desk Accessory Selector - by Les Kneeling
- ------------------------------------------------------------------------------
-
- Why use a selector?
- -------------------
- At first sight the amount of memory in an Atari ST appears to be
- enormous. There is, however, a fundamental law of computing which says that
- code will expand to fill the memory available and the last five years have
- confirmed this with the ST. Nowadays programs such as Degas Elite and
- Timeworks use up a megabyte of memory with the addition of a few fonts. Others
- like Calamus and Harlekin need a minimum of a megabyte to get going. Really
- anti-social programs like Signum leave enough space for the accessories but do
- not allow them to be called up.
-
- Until recently desk accessory selectors were written to get around the
- limit of six applied by the desktop. Now the amount of memory available in the
- computer is often the limit.
-
- How does it work?
- -----------------
- When the ST is switched on it goes through a number of stages of
- initialisation. It starts up the operating system, checks to see if there is a
- hard disk, runs programs in the AUTO folder, loads the desktop.inf file, runs
- GDOS, and loads desk accessories. The fact that it deals with the programs in
- the AUTO folder before the desk accessories means that an automatically run
- program can be used to control which ones are loaded.
-
- The computer assumes that a file in the root directory of the boot disk
- (or drive C if a hard disk is used) with a '.ACC' extension is an accessory,
- anything else is not. The crude, but effective, method used by every selector
- that I have seen is to rename unwanted accessories with a '.ACX' extension.
- This means that when the AUTO programs have run their course and the operating
- system loads the accessories, the '.ACC' ones will be loaded and the '.ACX'
- ones will not.
-
- The AUTO folder
- ---------------
- There are a few things to bear in mind when using the AUTO folder.
- First, the programs must have a '.PRG' extension even though they do not
- use GEM. The normal convention is that programs which do not use GEM have the
- TOS extension.
-
- Second, the order in which the programs execute is the order in which
- they appear in the directory. The desktop always sorts the directory listing
- in some way and cannot be used to predict which AUTO program will be run
- first. There are two ways around this problem. There are a number of programs
- in the Public Domain which will list the directory without sorting (DosAcc, my
- PD accessory has this facility and is available from the ST Club). The
- alternative is to create the AUTO folder from scratch and copy the programs
- into it in the required order of execution. Some experimentation may be needed
- to get things in the right order but most AUTO programs have come with some
- guidance. The exception is the hard disk patch AHDI - which must come first.
-
- Third, there is a little quirk in the operating system which crashes the
- computer after the AUTO programs have run and before the desk accessories
- load. Jeremy Hughes, of Fontkit fame, believes that the number of AUTO
- programs is the cause and recommends that a 'do nothing' program is included
- in the AUTO folder to fix this if it occurs. I think that the system crashes
- in a rather more random way than this but I admit that I have not researched
- it in any way.
-
- The Listing
- -----------
-
- That is the background to the program, now to the details. The listing is
- very fully commented but there are a couple of points which are worth talking
- about.
-
- AUTO programs run at a stage in the initialisation process where there
- are only two graphics resolutions - low and high. If the desktop.inf says that
- the computer should start in medium resolution this happens after the AUTO
- programs have finished executing. The first thing that the program does is to
- find out whether it is running in colour or mono and sets a flag. According to
- the state of the flag a two or four column display is produced.
-
- The program reads the root directory twice. First to find all of the
- files with a '.ACC' extension, and second to find the files with a '.ACX'
- extension.
-
- The filenames are added to a linked list. Each time a filename is read
- malloc is called to reserve a new chunk of memory big enough to hold a struct
- which consists of a string to hold the filename and pointers to the previous
- and next entries in the list. Using the pointers the program can move back and
- forward through the list as required.
-
- The list is displayed on the screen and a call to Bconin() waits for
- keystrokes which are then fed to a switch-case statement for interpretation.
- This is a little more complex than it appears because Bconin() returns a long
- and the switch will only accept an int. It is possible to ignore this
- difference because the 'normal' keyboard characters are returned in the low
- word. On the other hand the cursor keys and other 'special' keys are returned
- in the high word. I used a union to get around the problem - it is treated as
- a long for the call to Bconin() and is split into key.split.lowword and
- key.split.highword so that it can be fed to the case statements.
-
- The last section of the listing is a group of procedures to make the
- screen handling more readable. Most of them are self explanatory, but perhaps
- auto_overflow_off() needs some explanation.
-
- When the screen is being used as if it was a character device (the VT52
- emulator), writing a character to the last character space on the last line of
- the screen will cause the screen to scroll. I wanted the menus on the bottom
- of the screen to go right into the corner so I called auto_overflow_off()
- before displaying them. This disables the trigger for the scroll and keeps the
- screen tidy. It is important to return the VT52 to normal - just in case.
-
- Finally
- -------
-
- The program was written to be extendable. In fact the facility to 'Clear
- all accessories' was 'bolted on' after the program was finished. Other
- extensions can be added simply by adding cases to the switch statements.
- Although it was written in Laser C it should work with any other K&R
- specification compiler.
-
- Bolt-on number 2
- ----------------
-
- To accomodate programs that allow accessories to be loaded from
- directories other than the root, I have added a configuration file to ACCSEL.
- To change the directory type c then enter the full path for the directory, say
- C:\accs and hit return. The display updates to show the accessory list. To save
- the configuration file type w. A file called ACCPATH is created in the root
- directory. This will be read next time the program is used and that directory
- will be set as the default.
-
-